C/C++ Interactive Reference Guide/C-C++ Interactive Reference Guide.iso/c_ref/csource3/137_01/apr84col.ddj

Text File | 1979-12-31 | 18.2 KB | 484 lines

.pl 61
.po 0
..
.. this article was prepared for the C/Unix Programmer's Notebook
.. Copyright 1984 Pyramid Systems, Inc.
..
.. by A. Skjellum
..
.he "C/Unix Programmer's Notebook"   for April 1984 DDJ.


                               Introduction

    Readers  responded to my December,  1983,  column where I discussed

perceived  deficiencies in the Unix operating system.   Their comments  are

included here in part.

    The  follow-up  discussion  on runtime libraries  and  link  format

incompatibilities are also presented here.

    It  was also my intention to discuss two C compilers which  support

the  large memory  concept on the 8086.   One of the compilers has not  yet

been  received,  so this comparative review will have to be included  in  a

future column.

    I have received several more letters concerning C layout standards.

While  we  don't  have room to include their  comments  at  present,  their

comments will undoubtedly lead to several columns concerning related topics

of interest.

                            Comments about Unix

    In the December column,  I mentioned several aspects of  Unix which

I believe constitute weaknesses.   Tony LiCausi of Canoga Park, California,

sent me a letter with his dissenting opinions.  He begins by remarking:

    "Unix was designed for the programming environment, for use by folk
already  familiar with computers.   Unnecessary I/O slows down a  program's
performance and hence should be eliminated.   Thankfully verbosity is often
eliminated,  in Unix,  as the default option.  However many of the programs
do  have  command line switches to increase the progress reporting  of  the
program."

    Unix  was  designed to circumvent the flaws of  existing  operating

systems. Under Unix, modular programs are coupled via pipelines to create a

convenient   working   environment   and  reduce  repetition   of   effort.

Furthermore,  Unix  offers unequalled portability between large  and  small

computer  systems.   Since  it  is successful  in  these  respects,  Unix's

popularity  is growing.   Hence,  more and more computer users are  gaining

access  to machines which use Unix.   Many of these users are familiar with

computers  and programming while others are novices to both  computing  and

Unix.

    Let's  assume that a user is well-versed in programming but is  new

to  Unix.   According  to Mr.  LiCausi,  this user belongs to the group  of

people  for  whom  Unix was designed.   I'll assume that the  user  has  an

application  in mind,  since the average user won't be writing programs  as

ends unto themselves.  To succeed in implementing his application, the user

will have to learn about various aspects of Unix,  including various  shell

commands, system calls, and runtime libraries.  However, I submit that this

type  of user will be slowed down significantly by overall poor quality  of

the Unix documentation.  Since examples in the Unix documents are typically

both terse and highly complicated, the typical user could spend an enormous

amount of time circumventing a single snag.

    Imagine  linking  the mathematical function library as part of a  C

compilation.  Two seemingly possible ways for doing this are:

        cc -o test test.c -lm

or

        cc -lm -o test test.c

It  turns out that the former method is correct while that latter  produces

undefined  function  error messages at  the  linker  stage.   However,  the

documentation  does not indicate that the '-lm' must be near the end of the

line.

    Our  hypothetical  user  will also be slowed down  by  the  cryptic

nature  of error messages.   It is true that the more  sophisticated  users

require  little or no prompting,  and only gentle nudges when they make  an

incorrect  entry,  but the vast majority of users probably don't belong  to

this category.


    Finally,  the  user  will  be slowed down by inexplicable  and  un-

documented bugs in systems such as troff and eqn which I mentioned  before.

Furthermore,  circumventing bugs requires highly specific knowledge.  Also,

the  solutions,  even if available,  may not be widely known.   On the Unix

machine I use,  only a small group of people are aware of the procedure for

avoiding some common, but annoying, bugs in eqn.

    Mr. LiCausi makes a very valid point concerning this:

    "Software  bugs are not acceptable in any form at any  time.   Unix
from  Bell Labs is sold as unsupported software.   Their attitude is,  'OK,
we'll  sell it to you but,  we don't want to here from you.'  There  is  no
mechanism  to  report or correct bugs at the source.   Source code  is  not
typically  available to the average user.   Source code is guarded on  Unix
like gold;  just like any other commercial software.  Having done debugging
of  the f77 compiler on one system,  access to other software (for  example
and integration) was severely limited."

    Thus,  while Mr. LiCausi contends that Unix was designed for people

with programming experience, he sets his standard for 'unnecessary I/O' and

'program  performance' based on the most sophisticated level of Unix  user.

Furthermore, it is still not clear to me why the sophisticated users should

be more willing to stand for poor quality documentation and user-unfriendly

software  than every-day users.   Finally,  it is not at all apparent to me

from  practical  experience  that 'many' of  the  standard  shell  commands

support extended progress reporting.

    Mr. LiCausi goes on to state:

    "The secret society of Unix is partially the result of the paranoia
of  'unauthorized access.'  The remainder is due to the lack of  commercial
incentive.   The  incentive has obviously increased as can be evidenced  by
the proliferation of books and articles on Unix anc C."

    I  stated in my previous column that some users perceive Unix as  a

secret society.  This is the case because they cannot grasp certain aspects

of  its  operation  based on the written and on-line  documentation  alone.

Only through initiated members can the knowledge (and undocumented  tricks,

patches  etc.)  be obtained.   Thus people feel left  out.   Other  popular

operating  systems do not have the same aura as Unix.   For  example,  CP/M

users  are  not  considered a 'secret society' even though  CP/M  has  non-

trivial  aspects.   Furthermore,  minicomputer  operating systems  such  as

VAX/VMS  (DEC) and AOS/VS (Data General) don't have the mysterious  quality

of  Unix.   That's because they have much more documentation to explain the

nitty-gritty of using the system.

    Mr. LiCausi finishes by stating:

    "Unix  is not user-unfriendly.   Admittedly it is beginner hostile.
Changes will be required to adopt Unix en masse,  ie for the micro,  but  I
hope that it does not spell the end of 'silent' software."

    My final counter-remark is that most users never become sufficently

sophisticated  in enough diverse aspects of Unix to escape the  feeling  of

user-hostility.   I personally run into difficulties, even though I've used

Unix for almost four years.  As soon as I use aspects of Unix which are not

part of my daily routine, 'gottchas' appear.

                           Other Points of View

    H.T. Gordon sent in a letter concerning Unix.  He writes:

    "It  was a pleasure to read the Skjellum critique of [Unix] in  DDJ
#86.   Since  C/Unix  is becoming the sacred cow of the computer  Brahmins,
few have the courage to point out its flaws.  It was designed by one of the
elite,  for elite users.  To them it's concise and elegant, even 'obvious.'
Only  rarely  is any explanation needed.   If it is,  a terse one will  do.
Prophets inspired by the high gods cannot waste their time spelling  things
out for mere morals in words of one syllable."

    I  don't  think that the state of C/Unix is as bad  as  Mr.  Gordon

suggests.   While there are problems,  I think that Unix has many strengths

and these strengths will be the basis for future operating systems.   It is

the  purpose  of this column to discuss strengths and weaknesses of  C  and

Unix  and  to propose solutions as well as to point out  the  problems.   I

encourage  readers  to  pose  solutions to these and  other  problems  they

perceive.
                        Low level Input-Output in C

    Patrick Cawood of Los Angeles writes:

    "I read with great interest your last article on tendencies in Unix
to produce poor operator interaction programs.   I seem to have met some of
the same in C."

    "In order to provide a secure operator interface, one does not echo
a keyboard character to the screen until it has been examined and  approved
by the program. But getch() function automatically echoes--even line feeds,
up arrows,  etc.!!   Function putch() provides an automatic line feed after
printing on the screen!!

    He goes on to state:

    "I  simply cannot believe that anyone would wittingly design  these
functions as they are,  or not provide any alternative hardware interfaces.
Especially  considering   some of the tasks I've heard were written  in  C.
But  perhaps these people writing serious software were all forced to write
their own hardware interfaces."

    The problem which Mr.  Cawood is referring to exists in a number of

non-Unix C compilers.   To begin with, let's review the problem in the Unix

environment.   Under  Unix,  putc() and getc() acquire and return a  single

character respectively.  However, to offload the host system, many terminal

interface boards programmatically handle user input-output in lines.  Thus,

before  any input is received by the host,  a whole line must  be  entered.

Naturally,   the   characters   are  echoed  by  the   terminal   interface

hardware/firmware,  and only limited line editing is permitted.  On output,

a  whole  line is buffered up before transmission to  the  terminal.   This

process  can be overcome by use of the 'raw' terminal mode (raw implies  no

host  character  processing.)   In this mode,  the  program  is  completely

responsible for input-output.  This mode is much more expensive in terms of

input-output  cost,  since the host must handle an interrupt for each input

character  and  perform  an  output request  for  each  printed  character.

However,  as I mentioned in the previous column, this is the only way for a

program  to get full control of what is entered and appears on the  display

device.

    With the introduction of C to microcomputers, compiler implementors

often based the behavior of the runtime libraries on their Unix experiences

rather  than  on The C Programming Language.   Thus,  whole lines are  pre-

buffered  by  typical  C runtime libraries before  a  single  character  is

received  by  getc().   Conversely,  a whole line of output  is  internally

buffered before it is printed on the display.   Thus, the runtime libraries

of  microcomputer C compilers often emulate the terminal hardware found  on

real  Unix systems.   However,  this is not what putc() and getc() are sup-

posed  to do.   In the truest sense,  raw mode is the fundamental  terminal

mode.   These  functions  should really work on a  character  by  character

basis.   C libraries should permit selection between the 'raw' and 'cooked'

modes (and echo,  no-echo) and thus permit input-output flexibility without

resorting to assembly language routines.

    One  C compiler which correctly handles the low-level  input-output

is the Q/C compiler from The  Code Works.   For example,  single characters

are only required when a getchar() call is made.   However, it doesn't seem

possible to turn off the echo.   Nevertheless,  this can be effected  under

Q/C,  since  The Code Works is kind enough to provide runtime and  compiler

source code.

                               Link Formats

    In  the October,  1983,  column I discussed incompatibility between

link formats.  Readers had quite a bit to say about this and their comments

are summarized here.

    Guy Scharf of Mountain View, California, writes:

    "I  find the incompatibility of linkage editor formats to be a real
problem.   For example, I want to use Digital Research's Access Manager and
Display Manager 86 with C.   I would prefer CI-86 (because I am used to it)
but  have  to  switch  to DRI's C because  of  the  link  format.   Another
compiler to learn and idiosynchracies to surmount."

    He concludes:

    "I'm not sure what to do about this problem (except complain).

    David D. Clark of State College, Pennsylvania, writes:

    "The  big problem isn't really the format of linkable files.   Even
compilers  that use Microsoft's M80 and L80 will not allow linkage to  code
produced  by  different compilers.   The function  calling  protocols  vary
tremendously  from  compiler  to  compiler.   BDS C  and  Q/C  have  fairly
straightforward function calling protocols.  Eco-C,  on the other hand, has
a  tortuous function calling sequence.   And even though Q/C and Eco-C  use
the Microsoft assembler and linker, the code files produced by them are not
compatible."

    The  problem that Mr.  Clark mentions is also present in  the  8086

(MS-DOS,  CP/M-86)  world.   Code from different compilers cannot be  mixed

because:

        1. each requires its own main function
        2. a wide variety of link formats exist
        3. calling conventions differ between compilers.

The  first two points are essentially insurmountable problems from the  end

user's point of view.   However,  the third point can be overcome by adding

dummy routines to convert calling conventions.

    Mr.  Clark makes some additional points concerning the deficiencies

of  the  8080 Microsoft .REL (relocatable) format.   These are of  interest

since many 8080 C compilers rely on this format.  His comments are included

in Figure I. in tabular form.

               ------------------FIGURE I.------------------
              Deficiencies in the Microsoft 8080 .REL format
                           and related software

    1.    M80  and  DRI's  RMAC  assemblers  only  support  six  unique
        characters (all upper case).  This is awkward for many purposes.

        2.  While  the  .REL  format apparently will  handle  seven  unique
        characters, neither M80 nor RMAC support this.

        3.   Apparently the .REL format,  M80 and L80 were designed to work
        with  the  FORTRAN-80  compiler which permits  only  six  character
        symbols.   This is an old standard,  and does not reflect the needs
        of  today's compilers.   The absence of case sensitivity in symbols
        is especially limiting.

            -------------------END FIGURE I.------------------


    It is obvious that an enhanced standard is necessary for the  CP/M-

80  world.   Even  under MS-DOS,  where Microsoft has enhanced the  linkage

editor format,  problems still exist.   These problems, as I perceive them,

will be discussed next.

    Microsoft's MS-DOS linkage format supports long symbols (31  unique

characters)  and has case sensitivity.   Thus,  it overcomes the objections

that  Mr.  Clark  posed for the 8080 .REL  system.   However,  one  nagging

problem  still exists.   This is the dichotomy between object  modules  and

libraries.   Because  of this dichotomy,  the MS-DOS linker always includes

the full contents of a .OBJ module during linking.   However, libraries are

searched.   In  order to make a library efficient,  each function  must  be

compiled into its own .OBJ file.  Each .OBJ file becomes a single sub-block

in  the library;  all the functions of that sub-block file are included  at

program  linkage.   If libraries and object modules were  equivalent,  this

problem  would be overcome since the functions of an object module would be

separable during linking.

                             Runtime Libraries

    Non-standard runtime libraries are a plague to  programmers.   They

inhibit  portability,  and  introduce  bugs when  software  is  transported

between different compilers.   Charles Brady of New South Wales, Australia,

writes:

    "An enormous contribution to standardization of C programs would be
the publication of a standard I/O library for BDS C,  with, if necessary, a
modified   runtime  package.    The  very  fast  and  efficient   compiler,
particularly  with  the symbolic debugger tool,  provides a  very  inviting
environment  for software development.   It is a great pity that this means
abundant non-standard C.  As there is no inherent reason why this should be
the case ...  someone should be able to ...  produce a Unix compatible  I/O
library."

    This  point is especially well-taken in view of the large amount of

BDS  C  software  available through the C User's  Group  of  Yates  Center,

Kansas.

    In  the  case  of  the runtime library itself,  there  is  a  clear

standard.  This standard is spelled out in The C Programming Language.  All

compilers  have  to  do  is support a  proper  subset  appropriate  to  the

environment in which they work.

                                Conclusion

    In  this column,  I have included the follow-up discussions on Unix

and  on link formats/runtime libraries.   The nature of the discussion  has

been  mainly  of  a  critical  nature.   This  is  not  intended  to  be  a

condemnation of the systems, but only an impetus for readers to suggest new

ideas to improve what we already have.   Unix is a worthwhile standard  and

should  be supported.   C is a valuable tool,  but can be  improved.   This

column  is a forum in which we can discuss,  develop and nurture new  ideas

about C and Unix.